13章 モデリング
モデル
動作原理やしくみを簡単に理解・説明するために、物事の特徴や関係性を図式化したもの (p.423)
モデルを作る活動：モデリング（＝章題）
「一貫性」という言葉のルーツは？ (13.3)
実装からモデルへのフィードバック (13.3.7)
モデルはどこでバージョン管理してる？
システム (13.2.1)
人間はシステムを用いて社会的活動をする
（営み、nrslibさん本）
システムは目的達成のための手段 (p.429)
目的達成がより効率化された別のシステムに代替
例：二足歩行 → 自動車や飛行機
コンピュータを利用したシステムが情報システム
システム構造を説明するために、単純な箱で図式化したものをモデルといいます。(p.430、13.2.2)
モデルはシステムの構成要素
👉モデルは目的達成手段（＝システム）の一部
特定の目的達成のために最低限考慮が必要な要素を備えたものがモデル (p.430)
モデルが同名だったとしても、目的によってモデルの内訳は変わる (13.2.3)
注文システムにおける商品モデル
注文に必要な要素：商品名など
配送システムにおける商品モデル
配送に必要な要素：サイズなど
（nrslibさん本）
Userクラス（モデル）は何がよくないか (13.3)
一貫性がない
（一貫性はエヴァンス本から？）
複数の目的のために無理矢理利用されており、モデリングしているようでモデリングしていない (p.434)
情報システムというのは、現実世界の概念のみをコンピューターの世界へ投影した仮想現実である (p.437、13.3.2)
現実世界の概念を仮想世界へ変換している
（アプリケーションを作るって、概念操作をしていたのか！）
概念的なやりとりをコンピュータによって高速化
情報システムの特徴
現実世界での物理的な存在と、情報システム上のモデルが1:1になるとは限らず、1:多の関係になるケースがある (p.439、13.3.3)
（Userクラスは1:1にしてしまっている）
1:1にすると一貫性の問題（複数目的に無理やり利用）が生じる
10章とのつながり
「意味の狭く、目的を表現した名前」
うまいモデリングのために：モデルを目的達成手段と解釈する (13.3.4)
IMO：ミノ駆動さんの主張の肝は目的と思われる]
システムは目的達成手段
モデルは目的達成手段の一部
モデルも目的達成手段
目的達成手段と考えることで、深いモデル(13.4)につながる
単一責任・単一責務の前に単一目的が来る (13.3.5)
モデルは1個または複数のクラスから構成されるもの (p.442、13.3.7)
図13.10 商品を複数のクラスから構成する例
商品名（値オブジェクトっぽい）
在庫数
深いモデル
モデル（目的達成手段）の発展
新たな構造、しくみによって、機能性をイノベートできる
（ここの「構造」は「具体的な実現手段」という意味ではないか）
情報拡散手段で機能性をイノベートした例：Twitterのリツイート
機能性の革新は優れた変換能力による
例：ECサイトは発注操作を発注データや決済データに変換
（発注データや決済データが処理された結果、商品が届く）
アイうた関連でのTwitter上でのやり取りを思い出した
（変換能力によって人を感動させるというようなこともできる可能性！）
本質的課題を解決し、機能性の革新に貢献するモデルを、ドメイン駆動設計（17.1.11）では深いモデルと呼びます。(p.453)
エヴァンス本の8章